Interoperable ORBs -- Providing a Communication Framework for Internet
Applications
by Peggy King
It is a truth universally acknowledged that a software project will take at
least twice as long to complete as anyone expected. In an attempt to prove
this corollary to Murphyφs law, the Standish Group, a computer industry
market research firm in Cape Cod, Mass., conducted the Chaos research
project. As part of the project, researchers surveyed over IT executive
managers in 1994 and again last year. The updated (November 1996) results
from a survey of 360 IT executive managers in charge of over 6500
applications suggest that the average time overrun for a software project
is about 222* percent. If your company runs on Internet time, such delays
can be costly. If you canφt get your companyφs programmers to work any
faster, another approach to the problem is to give them less to do.
Interoperable ORBs - Handling the Infrastructure
The information that Standish Group research analyst Karen Boucher compiled
for the Chaos project led her to conclude that about 70 percent of the time
spent on developing new applications is for creating infrastructure and
only 30 percent of the work relates directly to application-specific
requirements. Object request broker (ORB) middleware significantly reduces
the time and effort of writing distributed object applications because it
relieves developers of the chore of creating the framework that allows
objects to communicate. In an Internet or intranet application, creating a
communications infrastructure is an even larger task because objects behind
the firewall may need to communicate with objects outside of it, or vice
versa. The industry-recognized standard specification for ORBs, first
developed in the early 1990s, is the Common Object Request Broker
Architecture, or CORBA, from the Object Management Group (OMG) of
Framingham, Mass. CORBA 2.0,the latest version of the specification,
includes the Internet Inter-ORB Protocol (IIOP) which was written to assure
that CORBA-compliant ORBs can communicate with one another across the
Internet.
Organizations that buy a CORBA-compliant ORB rather than build their own
distributed object framework benefit in three ways ---time savings,
investment protection via standards, and potential for reuse. They save the
time it takes to build an application infrastructure and can concentrate
instead on creating business logic. If the organization uses a
CORBA-compliant ORB such as VisiBroker for C++ (formerly ORBeline) or
VIsiBroker for Java (formerly BlackWidow) from Visigenic Software Inc. of
San Mateo, Calif., its business objects can communicate via any other CORBA
2.0-compliant ORB. With interoperable ORBs, these business objects can be
reused even if the communication infrastructure is changed, for example,
when one company acquires another.
The Work That is Left For Applications Developers
Building Internet applications on top of CORBA 2.0-compliant ORBs can
significantly reduce the workload of an organizationφs IT department. The
CORBA specification includes an interface definition language (IDL) that
defines the external interfaces to business objects. The IDL defines the
'plumbing' (object types, attributes, methods, and method parameters) and
generates stubs (in C++) or skeletons (in Java). To build an application
from objects, the developers need only to know the interface definition for
the client on the front end and the objects on the back end. VisiBroker for
C++ and VisiBroker for Java both include an IDL compiler that reads IDL
source code and generates the communications code that is needed to check
network and/or open a network connection.
When applications are built on top of a standards-based ORB, the developers
are free to concentrate on the business-specific aspects of implementation
instead of focusing on what parts of an application can communicate with
other parts and how to accomplish the messaging. The only 'glue' code that
developers need to be concerned with is defining and writing the interface
for the business objects that they create. CORBA-compliant ORBs use IDL
language mapping specifications to create the code needed to perform data
conversions. These data conversions make objects created with one CORBA-
compliant ORB interoperate with other CORBA-compliant objects.
Visigenic recently posted a demo of a portfolio manager application it on
its Web site at www.visigenic.com along with instructions on how to
download its client applet from a Java-enabled browser or with Castanet
Tuner and Transmitter from Marimba software of Palo Alto, Calif. Although
it's possible to use this site to track ones portfolio because it contains
real-time stock quotes from Yahoo and the Security APL QuoteServer,
Visigenic intended the portfolio manager as a demonstration of how its ORB
products work rather than for trading purposes.
The Portfolio Manager is a CORBA 2.0-compliant Web-based application. The
client applet tracks financial information by making calls to remote
servers that manage the accounts, portfolios, cash balances, and financial
quotes for all users. The applet was implemented using Java user interface
code and VisiBroker for Java. It is deployed using objects running on
servers at Visigenic headquarters.
Multiple clients can simultaneously access the Portfolio Manager servers to
modify thousands of individual portfolios. Multiple users can also access
the same portfolio account simultaneously. The data for the stock traded by
users and for each portfolio account is maintained only on the servers,
making the Portfolio Manager a distributed application because the
financial data and the business logic are completely separate from the
client interface.
The Portfolio Manager is comprised of three tiers -- the client interface,
the servers and a communication layer. On the client side, there is
interface code written entirely in Java using the Java Applied Window
Toolkit (AWT). The graphics including the buttons, colors selections and
dialog boxes were all written using standard Java code so that interface
will look and feel nearly the same on any Web-enabled platform.
(Sun Microsystems, Inc.)(1997).iso/products/FrontPage/visigenic/visigen1.gif)
Click Here for Larger View
While the interface code on the client side is concerned only with the
display, the application logic is concerned with executing the commands
made by the user. Application logic code executes when a user with funds in
his or her account types in a stock symbol and a quantity of shares and
clicks on the Buy radio button. The application logic dictates which
servers to contact, what information is provided to the servers, and what
information comes back.
The business logic is on the server side where objects implemented in both
C++ and Java can reside on multiple servers. The Portfolio Manager has its
two business objects, one called Portfolio object and the other called
Quote object, which run on two separate servers. The client applet has a
client interface to tie the business objects together with the application
logic in order to make use of them, but the client computer does not store
the data. The Portfolio Manager uses the client interface to create an
account, add stocks to a portfolio and update them. Changes to an account
take place on a remote server rather than on the investorφs computer.
Distributed Object Communication With a Broker in the Middle
VisiBroker for Java resides in the middle tier of a distributed application
and provides the communication logic between the applet running on the
client and the objects running on the servers. The Portfolio Manager's
Portfolio and Quote objects have interfaces on which the client applet
makes calls, or requests. For example, the Quote object has a reference
called getQuote that instructs the object to retrieve the current price for
a stock specified by the user. In order to find and track object
references, the applet makes use of the object request broker to execute
the applet's calls, get responses, and send them back to the client.
Putting Smart Agents to Work
When an applet is brought up, it starts by performing a 'bind.' A bind
establishes the communication link with all the components required to run
the application. The Portfolio Manager applet binds to the Portfolio and
Quote objects. To do this, the applet contacts the Portfolio Manager's
Smart Agent, which is the part of VisiBroker for Java that locates the
business objects and routes messages from the applet. In the Portfolio
Manager applet, the Smart Agent knows the server on which the Portfolio and
the Quote objects are running. The applet lets the Smart Agent know that it
requires an object reference for the Portfolio object. The Smart Agent
responds with the requested object reference, enabling the applet to bind
to that object. From then on, whenever the applet makes a call on the
Portfolio object, it automatically communicates directly with the Portfolio
object. The only time the applet goes back to the Smart Agent is if an
object reference is no longer valid, as would be the case if the server
went down or if the object was moved to another server.
GateKeeper and Wrappers --- Getting Beyond Java Security Restrictions
Because of the security features built into Java, an applet can only
communicate with the actual host machine from which it was downloaded. For
example, if the server at Visigenic headquarters that hosts www.
visigenic.com contains the code for the Portfolio Manager, security
restrictions would prevent the application from communicating with any
other server. For a stock trading application, this restriction is
unworkable because it would mean that all the business logic for the
application must be stored a single server. To get around this restriction,
Visigenic developed a Gatekeeper that runs on the server from which the
applet is downloaded. Gatekeeper is written entirely in Java and can be run
on any machine running Java. The Gatekeeper provides the applet with all
the necessary codes, or classes. When an applet needs to bind to an object,
as the Portfolio Manager applet must bind to the Portfolio object, the bind
request goes first to the Gatekeeper. The Gatekeeper knows where to find
the Smart Agent, which it contacts to find the desired object. The Smart
Agent gives an object reference back to the Gatekeeper, which then
communicates with the applet to establish a bind between the applet and the
object. From then on, whenever the applet makes a call on that object, the
Gatekeeper serves as its police escort to allow it to move beyond the
security barricade.
Another obstacle faced by applets is communicating through firewalls. For
example, there is a firewall between the server at Visigenic where the
GateKeeper application resides and the server that hosts the company's
enterprise intranet. Applet communications are Internet Inter-ORP Protocol
(IIOP) messages, which are not usually permitted through firewalls. Working
with GateKeeper, VisiBroker for Java software handles this restriction
using a method the company calls HTTP tunneling. If a client attempts to
contact a server that is behind a firewall, it will try to make a
connection to the Gatekeeper. However, the connection will probably be
refused by the firewall because it's an IIOP message. If the connection is
denied, VisiBroker for Java writes HTTP code around the IIOP packet, in
effect wrapping HTTP around it and thereby masking the message as a
standard HTTP communication.
(Sun Microsystems, Inc.)(1997).iso/products/FrontPage/visigenic/visigen2.gif)
Click Here for Larger View
The Gatekeeper receives the HTTP packet and tries to parse the message as
an IIOP packet. When it fails at this, it tries to parse the message as an
HTTP packet. The Gatekeeper can pull off the HTTP wrapper, see the IIOP
packet and then parse that message. It then knows to return messages to
that client in an HTTP wrapper.
ORBs As Building Blocks for Mission-Critical Applications
ORBs are not merely enabling technology for individual applications such as
the Portfolio Manager. A growing number of enterprises are basing their
entire information architecture on distributed object technology. A large
early adopters, mostly in the financial services and telecommunications
industries, have spent years tracking emerging standards and developing
their object infrastructures. These efforts are beginning to pay off as the
enterprises reap the benefits of rapid application development. ORB vendors
have also begin to work with other software providers as implementation
partners for large, mission-critical applications. For example, Bank of
America subsidiary Concorde Solutions of Concord, Calif. is using Visigenic
ORBs along with TPBroker transaction processing monitor technology from
Hitachi America of San Jose, Calif. for the Credit Card Online (CCOL), an
on-line credit card system that currently includes about twenty business
objects. Banking customers who access their account information via Web
browser can now perform transactions such as checking their balances and
will eventually be able to transfer funds between accounts when the
appropriate objects are up and running. The Visigenic ORB functions as it
did in the Portfolio Manager demo -- it is the underlying technology that
provides a communications framework.
Back to Front Page